Kennzeichnung von sicherer Logik im FBS-Editor

Der FBS-Editor kennzeichnet eine sichere Logik, damit Sie die sichere Logik von nicht-sicherer Logik visuell unterscheiden können, wenn sicherheitsrelevante Anwendungen entwickelt werden.
Beim Legacy-Styling erfolgt diese Hervorhebung in Gelbtönen, während beim Smart-Styling spezifische Farben für die sicheren Datentypen verwendet werden. Siehe "Farbe/Stil für FBS-Elemente durch Datentyp bestimmt" für Details über die Farbgebung der Datentypen.

Für das Entwickeln von sicherheitsrelevanten Anwendungen müssen Sie eine Neuron Power Engineer-Version verwenden, die für diesen Zweck qualifiziert ist. Siehe die englische Dokumentation "Sicherheitshinweise zum Arbeiten mit der IDE" für die entsprechenden Informationen und gültigen Sicherheitshinweise. Wenden Sie sich an Ihren Systemintegrator, um diese Dokumentation zu erhalten.

Neuron empfiehlt, dass Sie und/oder Ihr Systemintegrator keine Gelb-Farbtöne bei der Gestaltung von FBS-Elementen verwenden, da "Gelb" für die Verfolgung von sicheren Signale beim Entwickeln von sicherheitsrelevanten Anwendungen verwendet wird. Diese Empfehlung gilt insbesondere dann, wenn Sie das Legacy-Styling verwenden. Neuron Power Engineer prüft nicht, ob Farben bereits anderweitig verwendet werden. Die Verwendung von Gelb-Farbtönen durch Sie und/oder Ihren Systemintegrator könnte also zur Folge haben, dass "Gelb" dann auch eine nicht-sichere Logik kennzeichnet.

Die folgenden FBD-Elemente werden mit der entsprechenden Farbe angezeigt:

Diese Logik im Legacy-Styling ist eine nicht sichere Logik, da der Datentyp INT verwendet wird:

Hier die gleiche Logik, jedoch mit dem Safe-Datentyp SAFEINT – wodurch die Elemente mit Gelb-Farbtönen angezeigt werden, um die sichere Logik zu kennzeichnen:

 

Sie können sichere Logik und nicht-sichere Logik auch mischen. Dabei ist die implizite Konvertierung eines sicheren Datentyps auf einen nicht-sicheren Datentyp erlaubt.

Unerlaubte Konstrukte werden als Fehler oder Warnungen im FBS-Editor gekennzeichnet werden. Da die implizite Konvertierung eines nicht-sicheren Datentyps auf einen sicheren Datentyp ein unerlaubtes Konstrukt ist, wird im obigen Beispiel die Zuweisung des ADD-Ausgangs auf die sichere Variable resultB als fehlerhaft gekennzeichnet. Grund: Die Eingänge des ADD-Bausteins sind mit nicht-sicheren Variablen verbunden.
Abhilfe: Rufen Sie die jeweilige Safe-Convert-Funktion auf, für das obige Beispiel ist das der TO_SAFEINT-Baustein:

Gut zu wissen
Unter "Darstellung der nicht-sicheren Logik gegenüber der sicheren Logik“ finden Sie ein Beispiel für die Darstellung im Smart-Styling.